Prograph App
Volume Number: 11
Issue Number: 7
Column Tag: Visual Programming
Why do I need Prograph CPX?
Building a full Macintosh application, with fourteen functions, in a
single session, without caffeine.
By Dr. Scott B. Steinman, Washington University, St. Louis, MO
Note: Source code files accompanying article are located on MacTech CD-ROM or
source code disks.
This article is an abridged version of the first chapter of the forthcoming book,
“Visual Programming with Prograph CPX” by Dr. Scott Steinman and Kevin Carver to
be published in Spring 1995 by Manning Publications/Prentice-Hall. Reprinted with
permission.
Introduction
Prograph represents an entirely new approach to programming using a visual
graphical representation of program code instead of source code text to build programs
more easily and efficiently. This article will introduce you to the Prograph
programming language and programming environment, and compare Prograph to
traditional programming languages. Since Prograph is so different from conventional
programming languages, we’ll present a complete example program to demonstrate
some of the revolutionary features of visual programming and Prograph.
Conventional High-level Computer Languages
In the early days of computers, programs had to be painstakingly written as a series of
ones and zeros. To simplify the task of computer programming, textual computer
languages were developed that used words and textual symbols to represent
instructions for the computer to carry out. These textual languages mirrored the
text-based computer environments on which they were used, such as the UNIX
command-line interface or DOS character-based screens. Several so-called
“high-level” languages have emerged in the past few decades, resulting in a veritable
“Tower of Babel” of computer languages - C, Pascal, Forth, BASIC, Prolog, LISP, Ada,
C++, SmallTalk and COBOL to name but a few.
With these languages, writing computer programs starts with planning a fixed
order of program instructions. This sequence is sometimes represented as a graphical
flow chart that shows where the program (or a section of it) starts and stops, when
data is input by the user or displayed to the user, the sets of calculations carried out,
and the logical decisions that the computer must make. The flow chart is designed to be
easily understood, so that the programmer can grasp the program’s structure at a
glance.
Unfortunately, after outlining his or her ideas in this easily understood pictorial
format, the programmer must then translate the sequence of instructions captured in
the flow chart to the textual style demanded by a given programming language. Textual
computer languages each have a unique rigid syntax for writing computer instructions,
just as human spoken languages have their own rigid rules for constructing sentences.
What is more important, the product of this program translation - the textual source
code (a sample of which is shown in Figure 1) - is now harder to understand than is
the graphical flowchart! For example, the reader of the code must examine it carefully
to see which text corresponds to an operation, a variable or a constant, as well as
which data is input to or output from the code.
So in writing the program, we’ve progressed from an easily understood graphical
representation of the program (its flowchart) to a less understandable collection of
words and symbols. And to top it off, we’ve spent extra time and effort to do this!!
Figure 1: Comparison of a flow chart diagram
to its equivalent C++ textual source code
To make things worse, computer languages are even more rigidly structured than
spoken languages. In an English sentence, for example, you could accidentally leave out
a comma or period or forget to capitalize a word, yet the reader would still be able to
understand the meaning of the sentence. If a computer programmer were to forget to
include a special symbol such as a semicolon or accidentally misspelled an
instruction’s name in a line of computer code, the interpreter or compiler “reading”
the program would be much less forgiving. It may either choose not to execute the
program at all or might run it incorrectly, freezing up or crashing the computer.
What is Prograph?
Programming would be much easier if we could just minimize the need for using
text-based computer language syntax. This is where visual programming, and
Prograph CPX™ in particular, comes in.
The Prograph programming language is a revolutionary departure from
traditional computer languages in that it hardly uses any text at all. Prograph is a
visual (graphical) language in which program operations and elements are
represented not as textual symbols but as pictures or icons (see Figure 2), much like
the way a graphical user interface represents disk directories and files with pictures
instead of words. It becomes much easier to tell apart the data from the operations at a
glance.
Graphical user interfaces tend to make computer users more productive.
Likewise, a graphical programming language makes programming more efficient.
Prograph programs may be built with a minimum of coding - a program written in
Prograph typically takes about one-third to one-half of the programming time needed
to write an equivalent program in a textual language like C. This makes Prograph an
ideal language for rapid prototyping of applications. This ease of use and efficiency
doesn’t sacrifice execution speed in the completed program. Prograph programs can be
compiled, and if you need a little extra speed for time-critical portions of the
program, you can even add external code written in lower-level languages like C.
Figure 2: Iconic dataflow programming
with pictorial representations of instructions
The efficiency of graphical programming has resulted in a number of high-level
iconic programming tools tailored to create specific types of programs for specific
types of tasks. For example, the LabView™ language (National Instruments
Corporation) is specialized for creating scientific and engineering programs for the
laboratory or industrial setting. Unlike these other visual languages, Prograph CPX
was designed first and foremost as a general programming language to build any kind of
program - graphical, word processing, scientific, business, musical, multimedia,
communications, and so on.
Prograph, like LabView, is not only visual in nature but is also a dataflow
language. Unlike textual programming languages, in which program control is laid out
in a rigid order, much like people read a book - from top to bottom - in dataflow
languages the program is represented as operations interconnected by links through
which data “flows”. In other words, while textual languages are control-driven, or
executed in the order in which instructions are written; Prograph is data-driven,
where instructions are executed when all of their input data is made available. This
means that computations and other operations need not be carried out not in a fixed
order. For example, in Figure 2, the “*” or multiplication command can execute only
when “*” has received the data passed out of both ask’s output data links towards “*”.
On the other hand, the exact order of execution of the two ask commands themselves is
less important, and they may be executed in any order (although we have the option of
forcing them to operate in a fixed order if we wish).
Programming in Prograph means “wiring together” elements that receive and
send data. Data flows into an operator, which acts upon it, then flows out of the
operator and on towards other operators along data links. Which operator executes next
depends upon when each operator’s data is made available to it. The ability to execute
operations in a less order-independent fashion will allow Prograph programs to take
full advantage of technology that will become more prevalent in the near future, such
as parallel processing computers. In Figure 2, separate parallel processors could
execute each of the “ask” instructions at the same time, speeding up program
execution even more.
The current generation of Prograph - Prograph CPX - includes such advanced
features as a comprehensive code library that provides a ready-to-use relational data
base and object-oriented user interface/application framework. But Prograph CPX is
more than just a computer language and code library. It is also an extremely
well-integrated program development system that includes interacting graphical
program editor, code interpreter, graphical debugger, and graphical user interface
builder. The Prograph programming environment allows you to plan the computer
program, write it, test it, and design its user interface - all with a single tool. The
debugger is an integral part of the program editor, so programs may be interactively
written and tested piece by piece. You can even add new parts to your programs as you
are running and testing them! After the program has been fully tested, Prograph’s code
compiler will produce a faster stand-alone version of your program.
Prograph also allows the programmer considerable flexibility in the choice of
programming style. Prograph supports the more traditional structural procedural
programming mode, as well as the newer object-oriented programming style.
Creating Prograph Programs
Let’s dive right in and examine an example program in Prograph so we can see some of
the key features of Prograph. We’ll make a simple address book program that will
maintain a list of contact addresses, allow the addresses to be viewed one at a time, save
the address list to a disk file and print each address. What’s extraordinary about this
program is that we will implement it by writing only 14 routines - even though the
program includes a full user interface!
A Prograph program is contained within a project, which is subdivided into one
or more independent modules of code and data called sections. Note that each section in
the Section Window (see Figure 3) has three icons. They represent the three
components of sections - classes, Universal methods and persistents. These three
components roughly correspond to object-oriented programming code, procedural code
and global data, respectively. Sections may be reused as needed in other programs. In
fact, our example program will be composed entirely of sections from the
object-oriented Prograph Application Builder Classes framework that we’ll reuse to
manage the program’s user interface.
Figure 3: Sections window for the Address List program
showing sections of the Application Builder Classes framework
We’ll add the 14 application-specific routines that we’ll write to one of these
sections - the one entitled First Example Workspace. This section is made to contain
self-contained units of application-specific user interface code. Specifically, we’ll add
new code to the existing object-oriented code or classes of this section (see Figure 4).
Figure 4: Classes of the First Example Workspace section
The majority of the icons in the First Example Workspace section depict some of
the classes, or packages of code plus data, that have already been supplied with the
Application Builder Classes framework, including the Application, Menu,
Document, Document Data, Window and Standard Menu classes. Each class
contains general code to manage one aspect of a user interface (in conjunction with code
within other sections of the framework); for example, the Menu class manages user
mouse selections of items in each of a program’s menus and enabling/disabling menu
items, while the Window class manages mouse selections within a window, as well as
window opening, closing, activation, drawing, etc. We’ll simply use these pre-existing
code modules in our program to control our program’s user interface for us.
Four of the classes in this window are special because they contain the
application-specific code for our program. These are the Address Book
Application, Address Document, Addresses and Get Address Window classes.
How do we create these new classes? We don’t! We let Prograph create them for us!
One revolutionary feature of Prograph is how well integrated its application
development environment is. The program editor, code interpreter and user interface
design tools all cooperate fully with each other. This degree of integration helps us to
build this program with a minimum of coding!
Prograph programs are built by first designing the program, then filling in its
details with code. Let’s begin by building the user interface of the program. By
selecting the Edit Application menu item in the Prograph environment, we enter a
series of graphical application user interface design tools called the Application
Builder Editors. The first of these is the Application Editor (Figure 5).
Figure 5: The Application Editor
We’ve given our program the name Address Book. Its four-letter application
signature (creator type) is ‘AdBk’. By selecting one of the three icons on the bottom of
the editor window, we can choose to edit the program’s menus, windows or documents.
Let’s look examine the program menus by opening the Menu Editor (see Figure 6).
Figure 6: The Menu Editor
At the top of the Menu Editor window is a preview of our program’s menu bar.
We’ve included two menus (aside from the standard Apple and Help menus for
Macintosh programs) - a File menu and an Edit menu. Note that we have the choice of
two varieties of pre-made File and Edit menus. We’ve chosen to use the Document File
Menu and the Basic Edit Menu, shown in Figure 7.
Figure 7: The Address Book program menus in the Menu Editor
By adding these two menus to our user interface, we’ve automatically added their
features to our program. And what features! These two menus implement complex
features such as document file saving and reading, printing and editing functions such
as cut, paste and copy, to name a few. Try programming these features yourself in C,
and you’ll appreciate the benefits of having them done for you by Prograph!!